Historically, signal processing has been performed using a combination of special purpose hardware and software designed for the specific digital signal processor environment used in a particular application. At times when no real-time operating system was available, the programmer had to be concerned with every detail of memory management, communications and scheduling. Even when real-time operating systems such as VxWorks have been available, the signal processing programmer typically needed to be concerned about the specific memory, input/output, and communications architecture of the processor used.
As a result, signal-processing software was difficult to reuse. In the past, signal processing has placed strong demands on processing throughput, often approaching the entire processing capacity of the computer or computers used. To maximize performance for the capability of a given computer or set of computers, the design and implementation of the signal processing software was closely tied to the particular hardware architecture and was also closely tied to the particular operating system and related libraries previously developed. Hence, reuse was difficult due to the fact that this signal processing software was closely tied to the particular hardware architecture and operating system used. This signal processing software required optimization for a particular application and was designed for specific functionality rather than to comply with an overarching architecture for reuse. Presently, due to the complex nature of signal processing tasks involved, specialized equipment and software is developed for each and every one of the signal processing requirements. What results is a multiplicity of processor types, a multiplicity of operating systems, and a multiplicity of hardware components, none of which are reusable from one application the other.
With the advent of more capable general-purpose processors and operating systems, whether real-time or not, it became possible to consider a more general and reusable approach to signal processing.
Many vendors now provide computer modules in the form of cards with one or more processors, memory, and input/output with high performance and integral communications capabilities. These communications are often provided by dedicated hardware on the computer modules and are usually designed to be scalable so that as modules are added to the system, the communication bandwidth is also increased. However, generally these computer modules are dedicated to one specific type of operating system and related libraries. The task of reusing signal processing applications when converting from one computer module to another, particularly between different vendors, remains a difficult, time consuming, and expensive task.
There is therefore a need to find means to exploit modern hardware and software engineering approaches to define an architecture for signal processing that would allow for software reuse and rapid system development owing to that reuse. It is also important that the architecture developed not be tied to any particular processor type or hardware so that one can quickly take advantage of processor improvements, or at least not fall victim to the disappearance of a particular processor type or hardware from the commercial marketplace.
For instance, in an airborne communication, command, and control payload, there are various functions that such a system must perform. These include a communications relay function, signals intelligence processing function, acoustic signal exploitation function, and identification of friend-or-foe function. In the past, each of these functions required a separate set of processors and specialized hardware. The payload system integrator was required to incorporate in the equipment bay a number of highly independent sub-systems of specialized equipment, because common equipment could not be reused or reconfigured to provide the required functionality. In the equipment performing the signal intelligence processing, one needs to have a receiver interface, a signal energy detection system, signal recognition capability, radio direction finding capability and a countermeasure system that can include jamming. Each of these functions was priorly performed by separate processors and specialized hardware. It is interesting to observe that the a communications relay function, acoustic signal exploitation function and identification of friend-or-foe function require similar, if not identical capabilities.
In the past, in order to accomplish each of the above-named functions where one has very limited payload restrictions, the payload equipment and software was selected prior to flight in which only one capability was permitted per mission. It is desired to be able to reuse various processing capabilities and hardware capabilities for multiple tasks, permitting multiple capabilities per mission.
Thus, one of the major problems with writing software for signal processing in the past has been the inability to reuse software that previously has been developed for specific applications and particular hardware suites.
Previously, distributed signal processing applications were so demanding that they were written to be tightly coupled to a particular computer platform, a particular operating system, and the communications infrastructure that was being used. Reuse for different applications was virtually impossible. Further, when the computer platform changed or the communication infrastructure changed, that software had to be re-written.